Modular distributed mobile data applications

ABSTRACT

Computer-implemented system and methods for deploying a distributed client-server system, enabling developers to rapidly create and deploy read-write distributed data interfaces for host database systems. The disclosed system is especially advantageous for mobile clients as connection to the server environment can be intermittent without unduly impeding local (disconnected) operations. One important aspect of the invention is an incremental process for executing an application servo in a client device. This process includes building and incrementally maintaining a logical context tree in which each node expresses a complete current state of the execution process.

[0001] RELATED APPLICATIONS

[0002] This application is a continuation of U.S. ProvisionalApplication No. 60/251,285 filed Dec. 4, 2000, and incorporated hereinin its entirety by this reference.

COPYRIGHT NOTICE

[0003] ©2001 ThinkShare Corporation. A portion of the disclosure of thispatent document contains material which is subject to copyrightprotection. The copyright owner has no objection to the facsimilereproduction by anyone of the patent document or the patent disclosure,as it appears in the Patent and Trademark Office patent file or records,but otherwise reserves all copyright rights whatsoever. 37 CFR §1.71(d).

TECHNICAL FIELD

[0004] The present invention relates to software systems for distributedmobile computing and, more specifically, it includes a softwareplatform—and application language—for deployment of portable, reusable,and interoperable data viewing and modification applications in adistributed, intermittently networked environment.

BACKGROUND OF THE INVENTION

[0005] Increasing numbers of workers are mobile, meaning that they dotheir jobs outside of the conventional office. Laptop and palm-sizedcomputers provide some communication and computing ability “on the road”and, with the decreasing size of data storage devices of all types,mobile workers can carry a lot of data with them. It is more difficult,however, to share data with others or access a centralized database.Specifically, mobile users (or developers of wireless data systems) faceseveral challenges, such as:

[0006] Disconnected operation. Workers often lose connectivity incertain areas such as, subways, buildings, etc. but they should be ableto continue doing their job and, at a minimum, not have their datacorrupted (either locally or centrally) as a result of thedisconnection.

[0007] Limited screen size and user input. It is difficult to displaylarge amounts of information, and enable a user to meaningfully “browse”the information on a tiny screen. User input is limited as well,especially with respect to PDAs and cellular phones.

[0008] Latency. Another challenge facing developers is how to designapplications that make best use of a range of bandwidths.

[0009] Manageability. Applications should be able to grow, addingfeatures and functions, without rebuilding them from scratch and withoutlosing backward compatibility with other programs or services.

[0010] The value of separation of data and format has become widelyknown, one example being the use of stylesheets as described in U.S.Pat. No. 5,860,073. Stylesheets alone, however, do not adequatelyaddress the mobile user problems outlined above. For example, astylesheet or transformer can be written to translate data to HTML orWML for display on a small screen. But if the result is long,downloading may take awhile, and even if communication bandwidth isgood, disconnection is a risk, and even after downloading, limited localprocessing power may result in long delay before the entire document canbe randomly accessed by the user. Stylesheets enable some dynamicproperties, but when applied in the context of a Web browser pageviewing they do not provide a complete solution for disconnectedoperation.

[0011] XML (Extensible Markup Language) is a known document processingstandard (a simplified form of SGML). It allows a developer to create acustom vocabulary or “schema” defining a custom markup language. Thiscan be done using a document type definition (DTD) or with the XMLSchema Definition (XSD), among other schema languages. The schemaspecifies what elements or tags and attributes can be used in a documentand how they relate to each other. Many industry-specific DTDs areevolving, for example MathML, PGML, etc. XML parsers are publiclyavailable for checking “well-formedness” of a document (compliance withthe XML syntax specifications) as well as “validity” meaning compliancewith the applicable schema.

[0012] The Information and Context Exchange (ICE) protocol is designedto manage establishing “syndication” relationships and data transfer forcontent distribution. ICE is an application of XML. ICE enablesestablishing and managing syndicator-subscriber relationships fortransferring content that is generally originated by the syndicator andconsumed by the subscriber, such as news or weather reports. This systemessentially supports one-way distribution of content, i.e., publication,rather than interactive, mobile applications implementing andsynchronizing distributed databases. Still, it does suggest a datareplication scheme mediated by XML messages.

[0013] It has also been suggested to use text-based descriptiveattribute grammar, like XML, to specify object-oriented applications.U.S. Pat. No. 6,083,276 to Davidson et al. describes such a method. Itis limited, however, to essentially translating the applicationdescription (in an XML-like language) to a set of software objects suchas Java® component classes. Each element declaration in the source(markup language) file must be capable of being mapped to acorresponding application component class. Each element with childrenmust result in a corresponding container component with analogous childcomponents. Every attribute declaration must map to a correspondingproperty value in the corresponding component, and so on. Thus theapplication must be designed from the outset to align very closely witha selected object-oriented language and framework. Desiredextensibility, reuse and similar goals are sacrificed, although theconcept of initially describing an application using an XML-like syntaxis interesting and has some obvious benefits. The '276 patent toDavidson, however, primarily teaches an automated method for translatingthat description into a specific object-oriented program at which pointthe benefits of the descriptive attribute grammar are lost.

[0014] U.S. Pat. No. 6,012,098 teaches a system for isolating theretrieval of data from the rendering of that data. A data retrieval“servlet” executes a query, and converts the results to an XML datastream, delivered to a downstream rendering servlet. The renderingservlet parses this XML data stream, using a stylesheet that may bewritten using XSL, and creates an HTML data stream as output forcommunication to a client computer.

[0015] XSLT, or Extensible Stylesheet Language-Transformation, is auseful tool for working with XML documents. XSLT enables one to extractand transform the source information in various ways, for example intoanother markup language like HTML as is commonly done. See FIG. 1.

[0016] Many software systems exist which implement or utilize the XMLfamily of standards (XML, XSL, XPath, XML Schema Definitions, etc.).HTML and XML browsers are common. Many enable offline operation byaccessing cached read-only data. HTML and XML editors are common aswell, all of which form part of the general background of the invention.

[0017] See also U.S. Pat. No. 6,167,409 to DeRose et al. “ComputerSystem and Method for Customizing Context Information Sent with DocumentFragments Across a Computer Network.”

[0018] Glossary of Prior Art Terms and Acronyms

[0019] Application server—One of a class of commercially availablesoftware frameworks for integrating computation into a web serverenvironment.

[0020] Load-balancing router—A router that takes into account theeffective performance of a set of computational resources when decidingwhere to route a message.

[0021] N-tier architecture—A software architecture in which computingresources can be layered to any depth. In contrast to “3-tierarchitecture.”

[0022] Namespace name (Namespaces)—A URI uniquely identifying anamespace. See Namespaces in XML [Namespaces].

[0023] Public identifier (SGML)—Globally unique string to identify aresource. Could be accompanied by a system identifier, which was often afilesystem path on a private filesystem.

[0024] Public identifier (XML)—Unique identity string. See XML 1.0[XML].

[0025] Self identity—Identity as self-assigned by an object, without thedirect assistance of an issuing authority. The UUID is a standardcreated to support the implementation of self identity. Self identity isneeded in situations where it is not necessarily possible or appropriateto request an identity from an authority.

[0026] Session—An object representing a cached state to optimize an enduser's interaction with the system.

[0027] Synchronization point—The event during which a databaseincorporates information from another database, thus instigatingreplication or updating previously replicated information.

[0028] Unique identifier—Any identifier that defines a set of rules,that, if followed, guarantee uniqueness.

[0029] XML Extensible Markup Language—A simplified form of SGML, theStandard Generalized Markup Language, in international documentationstandard. XML is a document processing standard recommended by the WorldWide Web Consortium (W3C).

[0030] XSL Extensible Stylesheet Language—A part of the broader XMLspecification. An XSL document or stylesheet transforms an XML inputdocument to an output document, essentially applying element formattingrules.

[0031] XSLT Extensible Stylesheet Language-Transformation—The transformportion of the broader XSL language specification.

[0032] XPATH—A syntax for describing a node set location in an XMLdocument using expressions that consider the context in which theyappear.

[0033] URI—Uniform Resource Identifier. See RFC2396 [URI].

[0034] UUID—Universally Unique Identifier. A 128-bit unique identifierthat can be allocated without reference to a central authority. FromUniversal Unique Identifier [DCE].

SUMMARY OF THE INVENTION

[0035] The present invention includes computer-implemented methods formodular programming on distributed devices that brings together andextends industry standards in a unique way to create a platform for aclass of portable, reusable, and interoperable data viewing andmodification programs that can operate in a distributed, occasionallycommunicating environment, for example where client devices are looselylinked to hosts or servers via a wireless communications channel. Theinvention builds on XML and related standards, including, but notlimited to, Namespaces in XML, XPath, XSL , XSLT, XPointer, XLink, XHTMLand XML Schema Definitions [XSD].

[0036] A complete distributed programming model is achieved by enablingdeclarations of shared or private data storage, declarations of schematranslation, synchronization rules, editing actions, access rules,application packaging, label sets for default interfaces, andregistration for distribution and reuse. The invention exploits schemato enable seamless integration at both data and display levels. Anapplication defined for the invention can extend another onedynamically, even if neither developer was aware of the otherapplication.

[0037] Thus, one important aspect of the invention is acomputer-implemented, incremental process for executing an applicationservo in a client device. This process includes building a context treein which each node expresses (by reference) a complete current state ofthe execution process. For example, the context node content includes apointer to an element in the servo execution of which spawned thecontext node; a pointer that identifies a current data context bypointing into a source tree; a reference to a parent context; and anordered, potentially sparse, list of pointers to zero or more childcontexts.

[0038] Another feature of the incremental execution calls for thecreation of child spacer nodes in the context tree representingunmaterialized child contexts. These can be used for certain operations,and estimates, without waiting for evaluation of the entire source tree.In a presently preferred embodiment, the context tree is implementedusing a relative b-tree structure, and each spacer is reflected in aninterior node entry in the relative b-tree structure to facilitatesearching unmaterialized contexts.

[0039] Another aspect of the invention is a servo definition languagefor defining a distributed application that supports disconnectedoperation. The language typically includes the following types of rules:application data schema; transformation rules; transaction handlingrules; and interface object specifications. Importantly, the servodefinition language can also implement opportunity rules to realizeautomatic extension or integration of servos through opportunity-basedlinking of an interface component representing an instance of a schemafragment to a template.

[0040] The invention enables developers to rapidly create and deployread-write distributed data interfaces for systems that employrelational databases or have XML interfaces. Even when wireless networkservice is available, efficient use of the network is important for theend-user and/or the service provider (depending on the pricing structureof the service contract). The invention addresses this by allowing manyactions to be taken without immediate use of the network.

[0041] Wireless service is unreliable and often unavailable (e.g., inbasements, rural areas, and commercial aircraft). While it is notpossible to access new information when service is not available, theinvention makes it possible to review recent actions and initiate newactions of common types. Further, the present invention enables thedevelopment of continuously evolving suites of applications bymaintaining integration with legacy “servos” as new servos are createdand deployed. Users need not be actively involved in the distributionprocess. Developers can focus their efforts on individual capabilitiesrather than frequent systemic overhauls. “Servos” as used herein,roughly analogous to applications, are more precisely defined later.

[0042] Additional aspects and advantages of this invention will beapparent from the following detailed description of preferredembodiments thereof, which proceeds with reference to the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0043]FIG. 1 is a simplified data flow diagram illustrating a commonbatch XSLT transformation process as known in prior art.

[0044]FIG. 2 is a simplified data flow diagram illustrating interactiveservo execution in accordance with the present invention.

[0045]FIG. 3 is a simplified block diagram of a distributed systemillustrating a deployment of the present invention in a wirelesscontext.

[0046]FIG. 4A is a code fragment from the asset management servo ofAppendix B.

[0047]FIG. 4B is sample data in the schema of the asset managementservo.

[0048]FIG. 5A is a multitree diagram illustrating execution of the servotemplate of FIG. 4A over the sample data of FIG. 4B.

[0049]FIG. 5B is an illustration of a screen display generated by theservo template of FIG. 4A.

[0050]FIG. 6 is an illustration of a context node for use in incrementalprocessing of a servo.

[0051]FIG. 7 is an illustration of an interior socket for use in forminga relative b-tree structure.

[0052]FIG. 8 is an illustration of an interior whorl for use in forminga relative b-tree structure.

[0053]FIG. 9 is a simplified illustration of a single b-tree structurefor use in constructing a context tree.

[0054] Appendix A is a listing of a software description language (SDL)schema consistent with the present invention.

[0055] Appendix B is a sample asset management servo expressed in theSDL of Appendix A.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0056] The following terms are used in the present description of theinvention. Some terms are described in this glossary only, while othersare explained in more detail below. It is provided here as a convenientreference for the reader.

[0057] Abstract interface object—An object that provides information toan end-user or other software component. An object that offers theability for an end-user or other software component to provideinformation to the software system, such as enabling a choice orproviding information in answer to a particular question.

[0058] Concrete interface object—An interface object representing aspecific interface component that interacts with a human or anothersoftware component. For example, a graphical user interface widget suchas a drop down list.

[0059] Context, interpreter—An object which encodes, through its owndata and the objects it references, the internal state of theinterpreter at a specific point of evaluation. This is explained indetail below. Computing server—A server used to run servos and reconcilewith backing stores and other datasources.

[0060] Database name—A string that can be used within one specificdatabase as a short handle to another specific database.

[0061] Datasource—An information resource that implements the datasourceprotocol. Datasources may include resident databases managed by theinvention, specific computational resources (such as applicationswritten using other technologies), or gateways to other Internetresources.

[0062] Datasource declaration—The means of specifying the existence andaddressability of a datasource. Datasources are commonly registered withthe registrar.

[0063] Datasource protocol—A specific protocol for accessing informationresources. SOAP [SOAP] is an example of a datasource protocol.

[0064] Default servo—A servo associated by the registrar with a schemato be used in the event that a user encounters data in that schema andhas not previously selected an application to use with that schema. Eachschema has at least one default application. Different servos may beassociated with different element and attribute declarations.

[0065] Directory services—A location broker that provides a navigableindex of available services.

[0066] Front-end server—One or more functionally equivalent servers usedto process incoming requests and route them to appropriate computationalresources using knowledge about the specific request (the content of thepacket). A front-end server(s) may be a component of a load-balancingrouter.

[0067] Incident reporting service—A service which tracks subscriptionsto events associated with particular resources, and informs subscriberswhen those events occur. Used most commonly to track dependenciesbetween source databases and databases that replicate parts of thesource databases.

[0068] Label—One or more strings or other objects such as sound orimages associated with an element, attribute, model group or othercomponent of schema that serve to provide identifying information foruse in a user interface.

[0069] Location broker—A component of the invention that can accept anidentifier for a resource and provide means to contact that resource.Resources are not necessarily local to the broker.

[0070] Opportunity—An association between a unit of schema and a view orother action that can provide a means to interact with, modify, or applyan operation to, an instance of that same schema.

[0071] Public identifier—The public identifier used by the invention. Aninstance from a managed URL space. Compatible by subset with publicidentifier (SGML), public identifier (XML), URI, namespace name, uniqueidentifier.

[0072] Public identity—Identity as known to a central authority thatissues unique identifiers. (For the invention, the authority is theregistrar and the identifier is the invention public identifier.)

[0073] Registrar—The system resource which manages the registration ofschema, applications and datasources. The registrar enables reliableidentification and data mappings as further described below.

[0074] Schema translator—A software component that converts data of onespecific schema to data of another specific schema.

[0075] Servo—The unit of application packaging provided by theinvention.

[0076] Servo definition language (SDL)—A language in which servos areexpressed.

[0077] Servo transition—The action in which use of one applicationnaturally leads to use of another by leveraging the common schema of theunderlying data.

[0078] Short identifier—Another term for database name.

[0079] Storage declaration—Declaration of a persistent storage tree. Seebelow.

[0080] Synchronizer—A component of the invention which uses transactiondefinitions, synchronization point identifiers, time stamps, datasourcedeclarations and database instance-specific parameters to maintaincorrect database state across a set of related databases managed by theinvention. Also called transaction engine.

[0081] System identifier—An instance of a UUID used as a form of selfidentity for resources such as databases.

[0082] Task allocator—A service that assigns interactive tasks toavailable computational resources based on suitability to purpose(server load, access to resources, availability of cached database orsession state).

[0083] Task scheduler—A component of the invention that assignscomputational tasks to available computational resources based onpriority, aging, deadlines, load, etc. Typically the tasks handled inthis manner are not in response to a current user request.

[0084] Transaction engine—Another term for the synchronizer.

[0085] View—A grouping of transformation rules and components thatdefine all or part of the interface for a servo.

[0086] View declaration—Declaration of view—View declarations define howthe application (servo) interacts with the user or another softwarecomponent.

[0087] Introduction to Servos

[0088] We refer to an application in accordance with this invention as aservo. More specifically, a servo is the unit of application packagingprovided by the invention. A servo is created by “declaring” it inaccordance with an appropriate servo declaration language. In accordancewith a presently preferred embodiment of the invention, an XML-basedServo Declaration Language (SDL) is provided, portions of which areattached as Appendix “A.” Those skilled in the art will recognize thatother SDLs along similar lines may be used within the scope of thepresent invention. Key aspects of the SDL will be described in detailbelow. In practice, a developer specifies (or references) an appropriateschema in the SDL and then specifies (declares) a desired application,or servo, consistent with that schema. The schema definition languagemay use a markup language-like syntax, such as XML. A sample servo,discussed in detail later, is shown in Appendix “B.” Another importantaspect of the present invention is an incremental process forinterpreting or executing an application servo in a client device (or aserver). This process is described in detail later.

[0089] All other things being equal, the less information the author ofa software application needs to provide, the less time the author willneed to spend to create and maintain the application. The presentinvention provides a concise way to declare distributed data managementapplications. The experience provided to the end-users is created byselectively combining servos, which may be created by different authors,and interpreting them on differing platforms. This process is assistedby keeping the quantity of specification provided by the developer to aminimum. Platform independence is achieved through a minimal platformindependent application definition, supplemented by platform specifictransformations where the defaults are not adequate to address the goalsof the application author.

[0090] As noted above, the present servo definition language (SDL) is anXML-based language in which servos are expressed. The XSL vocabulary isreferenced by the SDL schema. This enables developers who are familiarwith XSL to make use of their experience and allows some of theexperience gained developing servos to be used in other contexts.

[0091] Information about a particular session environment can be madeavailable (subject to security restrictions) for reference by SDLthrough a specially named input tree. Session environment informationcan include, but is not limited to, the physical location of the mobileuser, identification of client hardware, quantification of availableresources, and status of communication channel.

[0092] Application data is available (subject to security restrictions)for reference in SDL as individually named input trees, using the namesfrom storage declarations further described below. These stores can bereferenced as variables. Each characteristic of a servo preferably maybe identified as overridable or not. This enables or disablesuser-specific customization. A simplified diagram of data flow is shownin FIG. 2.

[0093] Consistent with a presently preferred embodiment, servos, data,and protocol (including queries and query results) are all representedin XML. For any computational task, the inputs, the outputs, and theinstructions preferably are all expressed using XML. Since XML is simpleand compact to transport, this computational model makes it simple todeploy more hardware to handle loads. This includes the opportunity toutilize thousands of servers as well as the opportunity to movecomputation to “smart” (invention-enabled) clients when appropriate. Italso provides the means to transparently shift the underlying databasemechanisms to suit the different performance characteristics ofdifferent stores.

[0094] Further, the present invention can be said to implement “n-tierarchitecture”—a software architecture in which computing resources canbe layered to any depth. The architecture allows independent informationsources over a vast scale to be accessed through a single interface.Rich schema and interschema translation services enable information toflow across the layer boundaries without loss of context as furtherexplained below.

[0095] Several specific features of a servo declaration are described indetail below. First, we provide some context by illustrating at asimplified high level an illustrative deployment of the invention,followed by a simple servo example. The sample office asset databaseapplication will then be used to illustrate incremental execution ofservos and the execution context tree construct.

[0096] Illustrative Deployment

[0097] In FIG. 3, a server environment 300 is shown as currentlysupporting two mobile users, Alice and Juan. A synchronizer component310 communicates with a corresponding mobile synchronizer 326 on Alice'smobile unit, such as a Palm Pilot or other PDA 322. Similarly, Juan'spocket PC 342 includes a synchronizer component 346. Alice's PDA 322includes local storage or data cache 324 where schema, rules (servos)and data are stored. A replica 320 of Alice's storage is shown on theserver 300. In operation on Alice's PDA device, an interpreter 328executes selected servos, interacting with data and with the PDA userinterface. Data in the local storage 324 is synchronized with thereplica data 320 on the server via the synchronizer components, asexplained in detail later.

[0098] The local data cache provides the local storage for thesynchronization engine described below. It facilitates the sharing ofdata across applications and provides support for disconnectedoperation. For example, an application managing purchase orderinformation can integrate seamlessly with an application managingcustomer information, creating a unified view.

[0099] Another aspect of the local data cache is the ability to providea unified interface to shared as well as personal data sources.Applications provide views that can join individual data, shared data,and group data. The synchronization engines on the client and the servermanage all this data. The local data cache in a presently preferredembodiment includes indexing so as to enable efficient random access tolocal data.

[0100] Juan's pocket PC 324 similarly includes Juan's local storage 344,including data, schema and rules (servos). An interpreter 348 on Juan'spocket PC executes selected servos, interacting with locally stored dataand the Microsoft Windows user interface, supported by the Windows CE®or similar operating system. As before, Juan's storage has a replica 340on the server 300 with which the mobile unit is synchronized. The pocketPC is an example of a “rich client” that would typically include, inaddition to the operating system software, a synchronization engine anda display engine.

[0101] The display engine's primary purpose is to translate interfaceobject specifications onto the display of the wireless device, providinga layer of abstraction between the code and the device operating system.This component allows application developers to create applications thatcan run on multiple device-types in ways that optimize the userinterface for each device.

[0102] Actions normally handled using multiple windows on a desktopcomputer, become possible using a single view on a small screen,enabling dissimilar applications to work together without modification.This important flexibility enables system developers to be moreresponsive than ever to the constantly changing needs of their clients.

[0103] The display engine features preferably include:

[0104] A unique class of concrete interface objects to assist usersmaking selections from large databases.

[0105] The suite of standard device interface objects—tables, picklists, buttons, etc.

[0106] A generic pop-up window supporting all UI and data typesavailable on the platform described herein.

[0107] The ability to bind a UI element to a piece of data withoutneeding to track changes backwards and forwards.

[0108] The transaction engine (or “synchronizer”) 346 addresses thechallenges facing users of wireless solutions when disconnection occurs.Traditionally, productivity grinds to a halt. Here, the transactionengine provides seamless operation—regardless of connected state—to theuser, enabling continuous productivity. Additionally, this featureenables the user to work asynchronously, in other words, every useraction does not require communication with the server. Thissignificantly enhances application performance.

[0109] The synchronization engine preferably includes the followingfeatures:

[0110] Transactional support-store, forward, and full rollback withsupporting UI components for handling related events.

[0111] Event synchronization control—a full suite of controls enablingdevelopers to determine when and how synchronization occurs, includingpriority for individual transactions and classes of data.

[0112] Background updating-allows the server to push information to theclient transparently.

[0113] Referring again to FIG. 3, Juan also has a WAP phone 350 that cancommunicate with the server 300 via a WAP Gateway 352. Anotherinterpreter instance 356 is deployed in the server 300 to execute servosselected by Juan via the WAP phone, and interact with him via the WAPuser interface 354. This illustrates a “thin client” deployment wherethe interpreter is deployed on the server rather than the client side.Wireless handheld data devices divide into two major categories: richclients and thin clients. Rich clients have local storage capabilitiesas well as processing power. Thin clients essentially only have theability to display data.

[0114] The present invention works for both environments. On richclients, the client-side code resides on the device itself. On thinclients, the client code runs in the server environment as a virtualclient and communicates with the device using available protocols.Offline functionality is not available with thin devices, but theyaccess the data in the same manner. Nonetheless, the presentarchitecture provides a consistent development environment for bothtypes of clients by running the XML-based interpreter, XML storageinterface, and synchronization protocols in a virtual client moduleresiding on the server.

[0115] Server environment 300 also includes a registrar service 330where each user's rules and schema are registered, as explained ingreater detail later. The registrar is a component storing the userapplications or “servos” as well as managing the deployment and updatingof new versions. It also is where data schema are registered, enablingthe seamless migration from one application version to the next andenabling a seamless mechanism for dynamically rolling out newfunctionality to client devices. This enables the developer to create apersistent richness of applications over time, and able to manage themultiple versions within an organization.

[0116] On the backside, the server environment is coupled to a legacyrelational database 390, by virtue of an integration toolkit 388.Another synchronizer element 370 synchronizes data between the replicastorage 320, 340 and the external database 390. The synchronizer 370 canalso utilize other XML services 380. The server environment 300 furtherincludes a group storage element 392 including schema, servos and data.

[0117] Finally, the server includes a server side synchronizer 310. Theserver synchronizer is the server's counterpart to the clientsynchronizer. Its main function is to speak not only to the clients, butalso to the backend databases. The server synchronizer includes thefollowing features in a presently preferred embodiment:

[0118] Client synchronization—provides synchronization services with amyriad of devices and handles data collision, store, forward, androll-back.

[0119] Backup and restore of local client data—allows users to use anyhandheld device and still retain both personal settings and local cache.

[0120] Interface with backend database—handles the transactions with thebackend databases ensure data integrity throughout the system.

[0121] Transactional services—manages changes in data and ensures dataintegrity between clients and servers in the event connectivity is lostduring the transmission of data.

[0122] In operation, a typical life cycle of a request from a mobileunit is handled as follows. An incoming request first sees aload-balancing router that parcels requests out to front end servers.This is part of the “server environment” of FIG. 3. Once received by afront-end server, the URL is analyzed by a task allocator to determinean appropriate computational resource. The allocator uses a locationbroker to determine what servers are involved (responses may be cachedfor performance) and a performance monitor to assess the availability ofthe resources.

[0123] Once received by a computing server, the request is sent to aninterpreter instance for decoding. If there is already an activeinstance for the user's session, a reference to it is obtained from thesession object and the request is sent to that instance. If not, a newinstance is created and the request is sent to the new interpreterinstance. These objects are not shown in FIG. 3 as it is primarily adata flow diagram. At this point, further processing is dependent on thenature of the request.

[0124] We define a computing server as a server used to run servos andreconcile with backing stores and other datasources. An applicationserver is one of a class of commercially available software frameworksfor integrating computation into a web server environment. And a“session” as used herein refers to an object representing cached stateso as to optimize an end user's interaction with the system. Theseobjects are not shown in FIG. 3 as it is primarily a data flow diagram.

[0125] At this point, further processing is dependent on the nature ofthe request. If the request involves accessing data that resides inanother database managed by the present system, a messaging service isused to post the request. The messaging service will use the locationbroker to determine where to send the message that has been addressedusing a platform public identifier. Public identifiers in this contextare URLs for resources assigned through the authority of the registrar.

[0126] If the request involves accessing information from an externalHTML source, the process is similar to above, except that the objectthat receives the message is not a database, but an adapter that knowshow to post an appropriate request (or set of requests) to the web andconvert the result into XML. (Portably written adapters that do not relyon cached state can be run anywhere, so the messaging system can chooseto resolve the request in the current address space.)

[0127] If the request involves accessing data local to the user'sdatabase that has been replicated from elsewhere, a synchronization logis checked to see if the database is within the grace period allowed bythe declaration of the datasource. (These services are further describedlater.) If so, the replicated data is used without furtherinvestigation. If the database is out of date, a request is sent to thedatasource directly using the messaging service. The datasource respondswith the synchronization packets required to update the local database.The update is performed and then the original request is processed.

[0128] A Simple Servo Example: The Office Asset Database Application

[0129]FIG. 4A shows a simple example of a servo template which wouldtypically appear as part of a servo declaration. FIG. 4B is a databasefragment associated with the servo template of FIG. 4A. Each line ofcode in the drawing is numbered at the left side (400-419 in FIG. 4A,420-434 in FIG. 4B). These numbers are provided for reference in thisdescription, they are not part of a sample code. Referring now to FIG.4A, the xsl:template declaration defines the corresponding fragment ofdata schema, in other words the associated data type, by reference tothe “wh:obj” element. Line 402 borrows the standard html tag fordefining a division of the output resulting from this execution. In line404, the html:span element employs the xsl “value-of” instruction,generally used to generate output, with the attribute select =‘@barId’.This is the XPATH formulation to obtain value of the barId element ofthe database object. Referring to FIG. 4B, the first object in line 422has the barId value equal to ‘271’. Consequently, execution of thisservo will output the number 271 as illustrated in FIG. 5B.

[0130] Referring again to FIG. 4A, line 406 asserts an edit instructionfrom the “ts” schema, with a matching criterion (“select”) of thedescription element (“desc”) of the same database. (“ts” alludes toThinkShare, assignee of the present application.) The edit instructionis defined in the schema of Appendix A. It provides for display of aneditable field in the user interface. In this case, it operates on thedescription element of the database, which appears in FIG. 4B at line424 having the string value “black metal cabinet.” Accordingly, thestring “black metal cabinet” is displayed on the user interface as shownin FIG. 5B.

[0131] The <ts:expandable> and <ts:hideable> elements are described indetail in Appendix “A”. The remaining lines of code in FIG. 4A aremerely closing tags.

[0132] Returning to FIG. 4B, a first object is described in lines422-426 and second object is described in lines 428-432. The secondobject is shown at line 428 as having a barId attribute value of ‘259’and last attribute value of ‘271’, the latter being a pointer to theprevious object. The second element 259 has a description “top shelf”which is then displayed as shown in FIG. 5B, by virtue of theapply-templates instruction shown at line 412 of FIG. 4A. Thexsl:apply-templates element selects a set of nodes in the input tree,and processes each of them individually by finding a matching templaterule for that node. The set of nodes is determined the select attribute,as noted, which is an XPATH expression that returns a node set. The keyused in this expression is a persistent one declared as part of theservo.

[0133]FIG. 5A is a portion of an interpretation multitree illustratingoperation of the servo template of FIG. 5A on the database fragment ofFIG. 4B. This is an abstraction of the context records created duringthe incremental process of executing an application servo. FIG. 5Aincludes essentially two related tree structures—the servo executiontree and the output or geometry tree. The execution tree comprises thecircles, for example, the root node circle 500, while the geometry treecomprises the squares in FIG. 5A. With respect to the execution tree,each circle corresponds to a “context” which in turn reflects a specificstate of the execution process. The tree begins at the root node 500which identifies the template corresponding to FIG. 4A.

[0134]FIG. 6 is a simplified illustration of a single context node(corresponding to one of the small circles in FIG. 5A). Each contextnode includes an interpretation tree parent pointer, an interpretationtree root, a geometry tree parent pointer, geometry tree root pointer,and additional context information as described below. Later, wedescribe the use of “spacers” as a proxy for a plurality ofunmaterialized context nodes, and a relative b-tree structure forencoding the interpreter context tree. First, we further explainimportant elements of the servo language.

[0135] Schema Declarations

[0136] The principal types of declarations are:

[0137] Schema

[0138] Labels

[0139] Abstract interface objects

[0140] Storage declarations

[0141] Concrete interface objects

[0142] Abstract interface objects

[0143] The currently preferred embodiment of the invention uses XMLSchema Definitions as the core vocabulary for defining schemas. Inprinciple, other means of specifying schema can be used. In addition,the invention provides enhancements, discussed later, which enhance theusefulness of schema in the context of the invention.

[0144] One such schema enhancement is called a “label.” Here, a label isone or more strings or other objects such as sound or images associatedwith an element, attribute, model group or other component of schemathat provides identifying information for use in a user interface.

[0145] Objects declarable as labels include, but are not limited to:

[0146] strings representing natural language

[0147] bitmap or vector graphics

[0148] voice recordings

[0149] other sounds, specified by any means

[0150] Textual labels of various lengths and languages can be providedby a servo author using the example syntax provided in Appendix A.Shorter strings can be used as abbreviated labels, longer strings orelement subtrees as descriptions or documentation providing userassistance. Labels are accessible to servo authors through an additionalXPath axis or an element vocabulary within the schema axis. Labels areparticularly useful for creating servos that must deal with a largenumber of different languages and/or schemata.

[0151] Additionally, certain abstract interface objects provided by theinvention make use of labels to generate user interface objects based onthe language context without need for explicit reference to labels viaXPath. For example, the < > element in the sample syntax provided inAppendix A specifies a labeled editable field, without need toexplicitly reference the label. Other abstract interface objects canmake implicit use of labels, including, but not limited to:

[0152] tables with headings

[0153] tool bars containing icons representing actions

[0154] voice prompts

[0155] Storage Declarations

[0156] A storage declaration is the means by which a servo authorreserves named persistent storage for use by the application and anyother servos that may be authorized to access the data. Storagedeclarations define a locally scoped name for a persistent storage tree,and specify the schema to which the storage tree must comply. Note thisrefers to a data schema, not a servo declaration schema. An example of astorage declaration is shown in Appendix “B.”

[0157] The lifetime of external data varies. Old stock quotes (completewith time stamps) have unlimited shelf life, but little utility to theindividual who wants only the latest quote available. Weather forecastsmay be updated several times a day, weather observations several timesan hour. Personalized recommendations from a commerce site may not needto be updated more than a couple times a week. For these reasons, theauthor can declare the lifetime of data obtained from a given source.The lifetime may vary for different elements of the schema.

[0158] Collaborative datasources, such as a shared shopping list, mayrequire a synchronization check each time they are accessed. The authordeclaring the storage can also declare the form of acceptable queriesand the corresponding query results. An illustrative example of astorage declaration schema is shown within the schema of Appendix “A. ”

[0159] Specifying Concrete Interface Objects

[0160] A concrete interface object is an interface object representing aspecific object which interacts with a human or another softwarecomponent. Some representative concrete interface objects include, butare not limited to:

[0161] 1. an editable text field

[0162] 2. a voice prompt answerable with a voice response

[0163] 3. an XML message sent to another subsystem, answerable by an XMLresponse message

[0164] 4. a one-of-n choice presented as radio buttons in a graphicaluser interface

[0165] 5. a one-of-n choice represented as a pull-down or pop-up menu ina graphical user interface

[0166] 6. a one-of-n choice presented as voice prompt offering choicesthat can be made by typing keys on a telephone or other device

[0167] 7. a paragraph element (“p”) in XHTML

[0168] 8. an XSL formatting object

[0169] A graphical user interface specified by the invention can useelements from a number of vocabularies, including XHTML, XSL. Inparticular, the common user interface elements, including, but notlimited to forms, buttons, menus, editable fields and tables may bespecified using any number of vocabularies. In addition to commongraphical user interface objects, the invention provides for use ofconcrete interface elements that provide structural views ofinformation. For example, the invention provides concrete interfaceobjects that expand to display additional concrete interface objects inresponse to user commands. These devices are particularly useful whencombined with opportunities, described below. The combination of theseinterface devices with the method of “view declaration” providesparticular advantage to users of handheld devices with small displays.

[0170] Specifying Abstract Interface Objects

[0171] Recall that an abstract interface object is an object thatprovides information to an end-user or other software component. Anabstract interface object can be used to enable an end-user or othersoftware component to provide information to the software system, suchas enabling a choice or providing information in answer to a particularquestion. The invention enables developers to specify a user interfaceor software interface using abstract interface objects that areindependent of the specific concrete interface object that may be usedwhen the specification is interpreted, for example when a servo isexecuted, in the context of a particular device or system.

[0172] Example abstract interface objects include, but are not limitedto:

[0173] choice of 1 of n options

[0174] choice of m of n options

[0175] ability to specify a value for a specific instance of an objectdefined by schema, providing the current value as an option

[0176] progressive disclosure of means to specify information

[0177] a group consisting of other abstract interface objects

[0178] Specification of an interface using abstract interface objects ispreferred over concrete interface objects because it enhances theportability of the interface thus defined.

[0179] Specifying Views

[0180] Recall from the glossary that a view is essentially a selectedgrouping of transformation rules and components that define all or partof the interface for a servo. It is implemented by a view declaration.View declarations define how the application interacts with the user oranother software component. See Appendix “A”.

[0181] The declaration of views uses the XSLT vocabulary combined withextensions. The XSLT input trees correspond to declared data storageareas, and the output tree is a specification of the interactive userinterface. XSLT provides a mostly declarative vocabulary fortransformation. The invention allows the input tree to be modified as aconsequence of transformation, as described in Specifying datamodification. Use of the XSLT vocabulary does not imply a. batch processfor transformation. The invention uses the vocabulary to specify aninterface that changes dynamically as the preconditions oftransformation change. This process is described in the Interpretingservos section.

[0182] Example extensions include, but are not limited to the followingelements, as illustrated in the schemas which accompany this document asAppendix “A”:

[0183] the <view> element

[0184] use of variables, available to XPath, which identify input treescorresponding to storage declarations

[0185] an additional XPath axis providing access to schema informationcorresponding to the addressed data

[0186] an additional XPath axis providing access to origin and changehistory of the addressed data

[0187] an additional XPath axis providing access to opportunities (asdefined below) associated with the addressed data

[0188] Operation of such extension is described in the interpretingservos section.

[0189] Specifying Opportunities

[0190] Recall that an opportunity is an association between a unit ofschema and a view that can provide a means to interact with, modify, orapply an operation to, an instance of that same schema. Opportunitiesthus allow servo authors to declare schema fragments for which the servocan provide alternative views or special actions.

[0191] For example, any number of applications can register the factthat they provide actions that can be performed on the address elementof a particular schema. These actions might include indicating whichside of the street the address is on, providing latitude/longitudecoordinates for the address, providing driving directions from thecurrent location, providing distance from current location, providing amap of the area, etc. These actions are available to users ofapplications that display data encoded in the target schema element.This is done both by allowing these templates or views to be calleddirectly and by run-time discovery of options and display of thoseoptions to end-users of the servos.

[0192] Opportunities associated with objects are available to XPathexpressions as functions and/or variables. This enables servo authors todiscover opportunities at run time.

[0193] The invention can also be configured so that the declaration ofan opportunity results in the opportunity being listed with certainabstract interface objects so that choices are presented to the userwhen the user is interacting with the object, regardless of what servois being employed.

[0194] Operation of servos can be further illustrated with the followingelectronic commerce example. The kind of information that consumers maykeep in databases managed by the invention can be extremely useful inpredicting future purchases. For example, a list of “movies I want tosee” can be interpreted as a list of “movies I want to buy.” Any numberof commerce servos can be introduced into a pre-existing set of servos,and be readily accessed from views of those servos by making use ofopportunities declared by those servos.

[0195] Take for example a servo “A” that manages a personal library, andreading list. The schema for the personal library contains various viewsof book metadata which utilize a schema that includes a <book> elementthat has an ISBN attribute. A servo can be added which declares one ormore opportunities associated with the <book> element, and offers ameans to submit and track orders to one or more book suppliers.Additional servos can be added to track all outstanding orders and toprovide status information from various carriers.

[0196] A servo can be used with a datasource that maintains userpreferences and makes recommendations, such as is found atmoviecritic.com or amazon.com. Such a servo can maintain a client sidelist of movie ratings that are reconciled with ratings found by crawlingthe site using the user's authentication credentials. When used incombination with servos oriented at purchasing or viewing products, theend-user is able to use multiple rating engines with the same set ofratings, and any set of purchasing servos. Thus, the invention can beused to help create electronic markets.

[0197] Other Types of Servo Declarations

[0198] Consistent with the presently preferred embodiment, operationsthat must be performed as a transaction are enclosed in transaction tagsin the context in which they are defined. Operations not so grouped areprocessed individually. Transactions can be nested. Editing actions arespecified using an XML vocabulary that covers operations that can beperformed on an XML tree, such as the editing actions supported by theW3C Document Object Model.

[0199] Specify Access Control

[0200] The sample schema given in Appendix “A” provides an example of anaccess control model. The invention can be used with any number ofaccess control models. Access control can be based on your role in acommunity, the specific data-types you are modifying, their context inthe database and the control attributes on those objects or theirclosest container having such control attributes.

[0201] Structure of Databases Managed by the Invention

[0202] The preferred embodiment of the invention uses a native XMLdatabase with persistent, incrementally updated indices. Alternativedatabase representations can include a simple XML file parsed and loadedat application startup, as well as a relational database.

[0203] The logical structure of the database is described here as if itwere represented in XML, although other persistent representations arepreferred, as explained above. Within each database are regions, whichcan contain, among other data:

[0204] identification information for the database

[0205] declarations identifying other databases

[0206] servos installed in the database

[0207] named storage regions associated with servos

[0208] a transaction log with all changes encoded in XML, including theoperations required to back out each transaction.

[0209] Example schema for a database is given in Appendix “A.” Thisdescription applies to both local storage and server replica storage(see FIG. 3).

[0210] Process of Interpreting Servos

[0211] Servos are distributed on request or by pushing the servodefinition into the offline store. The servos preferably are stored inparsed form. Alternatively, servos can be stored as unparsed XML.Alternatively, servos can be stored and distributed in a compiled form,such as would be used on a virtual machine, or actual machine code.Storing the servo as the data is stored enables the same tools to beused for storing, indexing, accessing, transporting, synchronizing andtransforming the servos. However, compiled representations can be usedto achieve better performance and/or smaller size. Byte code or machinecode representations can also be translated on device from unparsed XMLor parsed XML forms and cached locally to improve performance. Theinvention is described here in terms of the parsed representationoption. The incremental interpretation process described below appliesto XSLT transforms as well as servo definitions. The interpretationprocess requires first understanding the concept of “context” in greaterdetail.

[0212] Details of Context Content

[0213] Basically, an interpreter context is an object which encodes,through its own data and the objects it references, the internal stateof the interpreter at a specific point of evaluation.

[0214] The component that performs the incremental transformation iscalled the transformer. The internal state of the transformer isorganized into records, here called contexts. Each context specifies theevaluation state of the transformer at a specific point in thetransformation process. Each context node can include at least thefollowing content:

[0215] 1. A pointer to an element within the servo template, XSLTstylesheet, or a node within an abstract syntax tree of an XPathexpression contained in the transform. This serves as a program counter.This representation can be XSLT source, a parsed XSLT transform or afurther compiled representation such as instructions in an XSLT virtualmachine or hardware machine code.

[0216] 2. A pointer that identifies the data context. It is a pointerinto a source tree, or a result tree fragment.

[0217] 3. An ordered list of zero or more contexts that provide a symbolspace for the context. Intermediate contexts in the tree that do notintroduce symbols may be skipped.

[0218] 4. A reference to a parent context.

[0219] 5. An ordered, potentially sparse, list of pointers to zero ormore child contexts. In the preferred embodiment, these child contextsare contained in a data structure that encodes the relative order ofmaterialized contexts, including the ability to encode unmaterializedregions of unknown size. An example of such a data structure is a b-treein which materialized contexts and objects representing regions ofunmaterialized contexts are maintained in order. This b-tree structureis further described below.

[0220] 6. Definitions for symbols introduced by the context. Suchsymbols include variable declarations, parameter declarations, templatedeclarations, view declarations, and data declarations. Contextspreferably encode the differences from the symbol context inherited fromtheir parent(s). This includes declarations of variables and templates.Thus each context, through use of its parents, represents a completeXSLT processor state.

[0221] 7. In the preferred embodiment of the invention, the transformercontexts also encode the current synchronization state.

[0222] 8. Further, contexts can reference cache result trees, along withsignatures of the types of changes that would invalidate the cachedresults. These result trees can represent components of a userinterface.

[0223] b-tree Structure and Spacer Operations

[0224] Unmaterialized regions can be of known length or unknown length.Unmaterialized regions of known length encode the length of the regionas a count of missing contexts. This is called a spacer in the contextof the execution tree. Unmaterialized regions of unknown length aredistinctly marked and include an estimate of the number of missingcontexts. When there is no basis for a better estimate, a predefinedconstant is used.

[0225] As mentioned earlier, a spacer can be used as a proxy for aplurality of contexts. There is an obvious savings from not creatingcontext nodes that may never be needed. We leverage the b-tree structureto implement spacers. In a presently preferred configuration, we makeuse of the interior b-tree nodes, which are called interior whorls inFIG. 8, to stand in for the unmaterialized context or contexts. That'sdone within the interior socket structure as described with reference toFIG. 7, as part of an interior whorl, setting selected bits and, insteadof having a pointer down to a context, use that same storage to indicatethat the context is unmaterialized (which is to say it doesn't actuallyexist) and to indicate the number of unmaterialized objects thatcorrespond to that object, as well as estimates for metrics such as thesum of Y span element (b) in FIG. 7.

[0226] Also, at each level of the b-tree of FIG. 9, there are a set offlags which are used for a number of different purposes. Specifically,these can include flags that are searched for as part of the searchcriteria in the execution algorithm. Among them is a flag that indicateswhether there is unmaterialized context (spacer) present. The searchcriteria of the algorithm can quickly investigate whether there is acontext that needs processing, or it can search at the same time forunmaterialized contexts. (An unmaterialized context can be thought of asa context that needs a lot of processing. It doesn't even exist yet.)

[0227] When first processing an instruction that contains childinstructions, an unmaterialized region (represented by a spacer) iscreated to correspond to all of the child instructions. Searching forunmaterialized regions is the primary mechanism that draws the processforward and causes new contexts to be created. Here the term “region”refers to a fragment of the geometry tree, corresponding to a region ofuser interface, for example a portion of a screen display.

[0228] Once an unmaterialized region is found that satisfies a given setof criteria, for example whether it is on-screen, the interpreter can“carve off” a piece, at one of the ends or in the middle, creating a newspacer or adjusting the existing spacer as required to accommodate a newcontext node.

[0229] In a presently preferred embodiment, the context tree isimplemented using a relative b-tree configuration. FIG. 7 illustrates asingle interior relative b-tree node entry. Each entry in the interiornodes of the b-tree contains a value that is the sum of the lengths(including materialized contexts, unmaterialized regions of known lengthand unmaterialized regions of estimated length), and a flag indicatingwhether estimated lengths were included in the sum. These values arepaired with a pointer to the corresponding child node in the b-tree.

[0230] Referring to FIG. 7, the interior socket 700 includes (a) the sumof number of context node children, transitive over interior whorls, butnot beyond the first level of context nodes. Second, element (b)contains the sum of y span, transitive over all levels below. The nextelement (c) comprises flags, including the union of all flags below. Andfinally, element (d) is a pointer to the child (context node or interiorwhorl) or cached information about unmaterialized object.

[0231]FIG. 8 illustrates an interior whorl of the b-tree 800. In thisinterior node, each column 802, 804, 806 defines an interior socket asdescribed with reference to FIG. 7. FIG. 9 is an illustration of aportion of the interpretation tree. It includes a parent node 900 andplurality of child nodes, for example, 902 and 904. The relative b-treeimplements interior sockets 910, 912 and 914. In this system, each Wtnode can be parented separately by an interpretation parent and ageometric parent. In turn, each node can separately parent aninterpretation tree and a geometry tree.

[0232] Additional fields can also be included in the b-tree node entriesto track other linear values such as the y-axis of an image space thatcan be mapped to a graphical display. For example, this can correspondto the height of a PDA screen display. This data structure enablescontexts to be materialized incrementally. Relative addressing can beperformed in logarithmic time within spans of the tree that do notcontain unmaterialized regions of unknown size by walking the treestructure in the usual manner of traversing a relative b-tree.Similarly, absolute addressing can be performed in logarithmic time upto the occurrence of the first unmaterialized region of unknown size.Estimates derived from this data structure can be used to satisfy scrollcar sizing requirements of graphical user interfaces. In short, use ofthis data structure supports an incremental execution process thatenables immediate output to the mobile (or local) user regardless of theactual database size.

[0233] Contexts are evaluated by performing the operation implied by theinstruction addressed by the program counter and reflecting the resultin a context. The details of the evaluation depend on the specificinstruction. Evaluation actions include, but are not limited to thefollowing:

[0234] Variable and parameter declarations introduce symbols

[0235] Literal elements copy themselves to the output tree

[0236] Concrete interface objects are passed on to the user interfacesubsystem

[0237] Abstract interface objects are mapped to concrete interfaceobjects using platform-specific rules

[0238] Control constructs such as <xsl:if> determine which subtrees areprocessed further.

[0239] Creating a spacer to correspond to all child instructions.

[0240] Several techniques can be used to encode the types of change thatcould require that a context be reprocessed. Some optimizing space, someoptimizing the amount of unnecessary computation that is performed dueto false positives.

[0241] A context may express dependency on instances of a specificschema component. For example, an interpreter context which referencesan XSLT statement including an XPath query that depends on the value of“y” attributes on “x” elements could register interest in any changes tovalues of “y” attributes on “x” elements (including the addition ordeletion of “x” elements having “y” attributes).

[0242] Dependency on source trees can be generalized to an XPathexpression identifying nodes whose change would require reprocessing.Such an expression can be derived from XPath expressions in thestylesheet element addressed by the program counter.

[0243] An interpreter context whose processing result depends only onits ancestors and the value of a single element or attribute instancecan register an interest in that element or attribute instance.

[0244] All contexts express dependency on XSLT stylesheet contentthrough their program counter.

[0245] Contexts are marked “unverified” when state they depend on haschanged. When a context is marked unverified its ancestor contexts areflagged as having unverified contexts below. This can be used to rapidlysearch the context tree(s) from the root(s) for contexts that need to bereprocessed.

[0246] When an unverified context is selected for processing severaltechniques can be used:

[0247] The context can be evaluated, as if for the first time, in itscurrent context. The result of the evaluation is then compared to theprevious value.

[0248] The change log can be examined to determine the precise nature ofthe differences. In some cases (false positives) these differences canbe determined to not affect the result.

[0249] The change log can be examined to determine a correspondingchange to the output tree. For example, consider a query returning asomewhat different set of nodes. Nodes in only the new set must havecorresponding contexts created. Nodes in only the old set must havetheir corresponding contexts deleted.

[0250] In each case, if the context has an identical effect to itsprevious evaluation, no changes need to be made to the output tree, andno child contexts need to be marked as unverified as a result of theevaluation. If the result of reprocessing is different than the previousprocessing, any child contexts that could be affected by the differenceare marked unverified.

[0251] The choice of what context to process is driven by specificobjectives of the software component requesting the transformation.These objectives can include:

[0252] The need to fill the visible portions of a formatting object withcontent.

[0253] The need to satisfy a request for data that is the object of aschema translation.

[0254] Processing to prepare the system to respond quickly to likelyuser action.

[0255] In order to effectively manage limited resources the processorcan release contexts and associated fragments of the result tree.Release objectives can be set to work within a specific memory quota.The invention chooses contexts for release by scoring on the followingcriteria:

[0256] Contexts nearer the interior of the tree are preserved overcontexts near the leaves of the context trees.

[0257] Contexts which required substantial computation on previousevaluation are preserved over contexts which required littlecomputation.

[0258] Contexts which are responsible for less memory are favored overcontexts which use more memory.

[0259] Contexts which carry decorations of the source or result treesare maintained as long as possible.

[0260] Other Features and Advantages of the Invention

[0261] The present system preferably validates data modification byrejecting editing transactions that violate data schema constraints. Theentire effect of a transaction should be considered when validatingschema constraints, although individual actions that make up atransaction need not yield valid intermediate results. In particular,the net result of a transaction must leave attribute values that matchtheir declared type, and element structure that matches declared contentmodels. The existence or absence of attributes should also be consistentwith the corresponding element declarations.

[0262] The present system also rejects transactions that would violateaccess control constraints (described below) and transactions that wouldviolate data mastering. And the present system ultimately rejectstransactions that are rejected by the datasource that masters the data(described below). For maximum security, read and modification controlare enforced by the mastering datasource. Modification control isenforced on the client and offline replicas as well as the server. Bydefault, the database in which an object was created is the master forpurposes of replication. This means that any modification that can beachieved through that creating database (subject to access controlmechanisms) will be propagated to replicating databases assynchronization points with those databases occur.

[0263] The invention can be used in combination with encryptiontechnology to provide private and authenticated access to remotedatasources. For secure applications, the server preferablyauthenticates user identities when processing requests from clientdevices. User authentication is central to higher level securitymechanisms such as access control and management of paid subscriptions.

[0264] Embodiments of the invention also can use digital signatures toensure that servos delivered to a client device come from a trustedsource. This model is similar to Microsoft's ActiveX controldistribution model. A preferred implementation also provides robustaccess control mechanisms for users, content, and applications. Userscan be given rights only to certain applications or certain datadelivered to those applications. When a user registers for anapplication, his or her access rights are checked against theapplication's rights list that has been set up by the application'sadministrator. If the rights match, the user is allowed to install theapplication. Content can be given access control lists as well, enablinga single application to serve different levels of content to users withdifferent access rights. For example, within a corporate environment,only the authorized accounting staff would have rights to see quarterlyrevenue figures before they were announced, but everyone could seehistorical figures that had been previously publicly announced.

[0265] Application Rights Arbitration: The client can be configured toprovide a mechanism similar to the Java sandbox concept wherein theclient enforces a set of rules governing what types of actions anapplication can take. Rules govern things such as writing data to thedevice's persistent storage, interacting with built-in applications, andrequesting data from foreign servers. The user controls the settings forthese rules. For instance, the user may allow any action to be taken byan authenticated application whereas tighter security might be appliedto untrusted applications.

[0266] Content Authentication and Version Checking: In many businesssituations it is crucial to establish that information has not beentampered with and that all information components are of the rightversion. Consider, for example, the management of aircraft maintenancepublications where it is required that all current service bulletins bedisplayed and that no un-approved documentation is displayed. Thepresent system enables this to be accomplished through thesynchronization processes by authenticating all messages throughencryption, including messages which define configurations that arecurrent as of a particular time.

[0267] Schema authentication and Version Checking: The invention can bedeployed in an environment where servos come from a variety of sources.It is valuable in such cases to establish that new schema contributionscome from authorized sources and that incompatible versions of schemacomponents are not used together. Details of implementation will beapparent to those skilled in the art in view of this specification.

[0268] The server environment of the present invention also enablescontent and application providers to support subscription or pay-per-usedistribution. Content providers might require a paid subscription toaccess their content. Thus, users' subscription status can be taken intoaccount when checking access control. Content providers might alsoprovide pay-per-use content. Embodiments of the invention can providethe infrastructure for collecting payment and ensuring that pay-per-usecontent is only delivered to paying consumers. Again, the particulars ofimplementation will be apparent to those skilled in the art in view ofthis specification and in any event will vary with the particularapplication.

[0269] User Management of Asynchronous Transactions: End-users canengage in asynchronous actions and can inspect the status of the taskqueue. The preferred embodiment includes user interface components thatindicate when there are transactions in the following states:

[0270] Transactions that have not yet been communicated to the server ordatasource.

[0271] Transactions that have been communicated to the server but forwhich no response has been received.

[0272] Transactions that have been confirmed by the server as havingbeen successfully completed.

[0273] Transactions that have been rejected by the server but have notyet been viewed or acknowledged by the user.

[0274] Rejected transactions that have been viewed by the user but havenot been acknowledged.

[0275] These interface components enable the user to quickly determinewhat tasks have been carried out or need to be attended to. In addition,the system can provide user interface components that enable users toinitiate operations on transactions that are accessible through theinterface described above. These actions include, but not limited to:

[0276] Viewing transactions in the context in which they were created

[0277] Canceling transactions

[0278] Modifying transactions that have not yet been communicated to theserver and

[0279] Coping and modifying a rejected transaction to be resubmitted

[0280] Resource-Level Identity and Element-Level Identity

[0281] Embodiments of the present invention employ two kinds ofidentifiers: public identifiers and system identifiers. Publicidentifiers preferably are URLs for resources assigned through theauthority of the registrar (330 in FIG. 3). System identifiers are UUIDsassigned without the assistance of any central authority when resourcessuch as databases are created.

[0282] The invention implements a form of self identity as well aspublic identity because not all resources can be known to a publicauthority at all times. Take for example an environment in which theclient has been distributed to a group of individuals without currentnetwork access. These individuals must be able to begin using theapplication right away. Using the application, however, can involvesharing information with others. The identity of this information needsto be tracked as it travels, so a unique identifier must be assigned.Since a central authority cannot be contacted to assign a publicidentity, the system must fall back on using self identity to track theinformation.

[0283] For reconciliation accuracy, performance and automation, units ofinformation managed by the invention can be uniquely identified at afine degree of granularity. Indeed, the reader will no doubt appreciateby now that the granularity is limited only as defined by the applicabledata schema. Unique identifiers must be scoped in such a way that noglobal mechanism is necessarily required to dispense the identifiers.(Note however that a central authority could be used when available.)

[0284] Local and Global Identification with Short Forms

[0285] Recall that a “database name” is a string that can be used withinone specific database as a short handle to another specific database. Ashort identifier is another term for a database name. The databases thatthe invention manages are identified using UUIDs.

[0286] Fully qualified global identification of an object is achieved bycombining the identity of the creating database with a UID scoped tothat particular database. When within their originating database,objects can be identified using a locally unique identifier. Within aspecific database, other databases can be referenced using shortidentifiers which are scoped within the referencing database. Shortidentifiers can always be normalized to long forms to provide locationindependent identifiers.

[0287] In the sample embodiment, individual elements are identified withthe “ts:u” attribute, which is an attribute defined on a “base”archetype that facilitates management of data. All element types thatrequire generalized unique identification are below “base” in theimplied inheritance graph. The value of the “ts:u” attribute consists ofa database name followed by a local id, with a “#” separator. Forexample, in a database where “b” is a declared database name, an elementwith identify “2” scoped to within database “b” will have a “ts:u”attribute value of “b#2. ” Database names are declared with the<dbDecl > element in the sample schema found in Appendix A.

[0288] Elements which are not identified with the “ts:u” attribute areassociated with the nearest ancestor that has a “ts:u” attribute. Suchunidentified elements can be accessed with XML linking mechanisms. Thesepointers would be relative to the nearest ancestor with a “ts:u”attribute. UUIDs are encoded as a string of 32 hexadecimal digits with adash delimiter (“-”) after the 8th, 12th, 16th and 20th digits. For afull specification see the Distributed Computing Environment [DCE]specification. For example: “2fac1234-31f8-11b4-a222-08002b34c003” isvalid UUID.

[0289] In the sample embodiment, the UUID for a database is indicated bythe “systemId” attribute on the first “ts:dbDecl” element. The UUIDs forother databases having elements replicated in this database are given as“ts:uu” attributes on the “ts:db” element under the “ts:imports”section. The local alias for each database is given as the“ts:localAlias” attribute of its “ts:db” tag. (See the schema inAppendix A.)

[0290] While it is possible to fully normalize all data represented inXML so that it is isomorphic to a normalized relational databaserepresentation, and while this is an appropriate encoding for manyapplications, the invention does not require that this be done with alldata. This allows document-oriented characteristics to be provided bythe invention. These characteristics include presentation order forelements and choice of primary location for multiply referenced objects.

[0291] Element Surrogates and Structural Referencing

[0292] It is also suggested that instances of the invention include analiasing mechanism that allows the structure of cross-linked XML to befairly thoroughly checked with existing XML tools and allows thestructure of the database to be easily interpretable by humans. In thesample embodiment, the “base” archetype includes an “ts:aliasOf”attribute of type IDREF which can be used to reference an element of thesame type whose attributes and content serve as the attributes andcontent for the referencing element. Most processing utilities operateabove the level where knowledge of these aliases is necessary. Lowerlevel utilities expand these aliases as an automatic service.

[0293] This same reference mechanism can be the basis for elementinstance inheritance. This provides a means to extend data replicatedfrom others while minimizing resolution conflicts. Low-level utilitiesinterpret inheritance automatically. Transformers to expand aliases canbe used to simplify operations for downstream transformers. When aliaseshave been expanded it is possible to discover the original source of theinformation by examining special system maintained attributes oralternative XPath axes.

[0294] Since aliases can in turn reference other aliases, informationcan be added at each level. Any number of subtrees can contribute to thefinal value of an alias chain. Since multiple transformations can becomposed together it would not be uncommon for multiple instances of thesame record to turn up at some phase of the transformation process whenonly a single instance is required. The “ts:u” attributes describedabove are the primary mechanism for identifying copies and eliminatingduplicates when that is appropriate. By default, when an alias isexpanded, the resulting element acquires the “ts:u” attribute of thereferenced element. This is the appropriate action when the alias existsto facilitate a tree-oriented view of non-normalized data.

[0295] In the sample embodiment, the “base” archetype includes a“refPath” attribute of type IDREFS. When an alias is expanded, the valueof the “ts:u” attribute of the referencing element is appended to thelist. In the sample embodiment the “base” archetype further includes an“inhPath” attribute of type IDREFS. When an ancestor is processed thatcontributes attributes (other than “refPath”) or content to the expandedvalue, the value of the “ts:u” attribute of the ancestor is appended tothe list. The values of certain attributes can apply to an arbitraryamount of information which may be grouped together in a subtree.Attribute inheritance may or may not follow aliases. Whether or not itfollows is a choice of extended schema and/or application design. Whenpossible, personalization should occur through refinement (e.g., viainheritance) rather than through making individualized changes toreplicated data.

[0296] Managing Change

[0297] Recall that changes to data are the subject of messages betweenclient and server, as illustrated in FIG. 3. Editing actions arespecified in terms of operations on an abstract XML model. For example,operations as described in DOM. The invention creates logs of changes asthey occur. Edits are placed in the log prior to being performed. Thisis called an edit log or transaction log.

[0298] A sample syntax for communicating change information is providedas part of Appendix A. In particular, <syncRequest > messages arerequests for updates to a particular piece (or pieces) of replicateddata. Information in a syncRequest may include:

[0299] The “ts:u” attribute values (discussed above) of the root nodesof the subtrees requesting an update. This information is required forevery Sync Request.

[0300] The Sync Packet Id of the last committed Sync Packet. This Idcontains the sequence number or date/time value of the last committedSync Packet. This is to request edits that have occurred since thissynchronization. In the absence of this attribute, it is assumed thatthe first Sync Packet in the edit log is the starting point.

[0301] The Sync Packet Id of the last Sync Packet desired. This is anoptional attribute.

[0302] The document identifier for the document we are requesting editsto. In the absence of this attribute, we assume that the request is foredits to the local document.

[0303] Whether the document identifier is a public Id or a UUID. This isbasic typing information needed to resolve the document identifierattribute.

[0304] A collection of “ts:u” attributes of subtree elements we wish toexclude from the request. This is optional.

[0305] To support tracking changes in collaborative authoring contexts,the “ts:cre” attribute encodes the creation date/time of an instance ofan element derived from the “base” archetype. The “ts:mod” attributeencodes the modification date/time. Modification is defined as a changeto attributes (other than “ts:u”), the generic identifier, the order orexistence of immediate children, and change to any children not enclosedin one or more elements derived from the “base” archetype. Changes tothe “ts:mod” attribute are not themselves considered changes (this rulemay have no consequences since modification does not propagate beyondthe first ancestor element derived from the “base” archetype).

[0306] The “ts:cre” and “ts:mod” attribute values are based on systemclocks and cannot be trusted as the basis for synchronization, whichbrings us to synchronization points, described next.

[0307] Synchronization Points

[0308] We define a “synchronization point” as an event during which adatabase incorporates information from another database, thusinstigating replication or updating previously replicated information.Each database has its own linear address space of synchronizationpoints, preferably represented as strings of decimal digits. Everydatabase will maintain a record of at least the latest synchronizationpoint with every database from which it imports replicated information.Every database will maintain a record of at least all synchronizationpoints at which information may have been replicated out.

[0309] While it would be useful to keep specific bidirectional recordsof all synchronization points, this record keeping may be impracticalfor certain databases, for example, a database which serves as atemplate for a large number of other databases or a database onread-only media. Even if this information is always kept, the systemmust be constructed so as to recover transparently when such exportinformation is lost. In a presently preferred implementation, databasesare not required to keep a record of all databases which have receivedinformation replicated from them. Not keeping usage (reference) countswith transactional integrity implies a need for a distributed garbagecollection solution. Otherwise, one may not know how long to keepsynchronization packets. The server environment should provide amechanism for distributed garbage collection. This must not interferewith the moment-to-moment operation of the system at any time.

[0310] In our sample schema, the “ts:sy” attribute carries thesynchronization point identifier of the first sequence point followingthe element's creation or modification. Modification is defined as inthe definition of the “ts:mod” attribute. The “ts:sy” attribute is foundon the “base” archetype. The type of the value of the “ts:sy” attributeis a string representation of an integer. The “ts:db” elements under the“synchronization” element in the “context” section hold thesynchronization point log for each database. See the schema of Appendix“A” for details.

[0311] Scope of replication can be controlled as well. A database canexplicitly disallow specific data from being replicated outward. Adatabase can explicitly disallow specific data from being replicatedtransitively (i.e., more than one level). Since it is easy to copy data,constraints on replication and transitive replication are not strongsecurity measures. They are more a way of indicating, in an advisorymanner, how the originator of the data wants the data to be handled.Control parameters apply to the transitive closure of a subtree throughcontainment, but not through aliasing or other linking mechanisms. Thisis a case where the physical structure of the database dictates controlsemantics. Items referenced in the structure are not necessarilyprotected by protection of the structure.

[0312] Copies created using the services of the present inventionpreferably carry a copy attribute that indicates the identity of theoriginating element. The syntax of the copy attribute values isidentical to that of the “ts:u” attribute value described above. When asubtree is copied, a copy attribute is applied to each element derivingfrom the “base” archetype, identifying its corresponding source. Changesfrom other datasources are captured using one of a variety oftechniques. Examples are:

[0313] Tracking change during modification in the manner of theinvention

[0314] Comparison of backing store

[0315] Query based on modification stamp.

[0316] Use of database logging facilities.

[0317] The present invention also very effectively addresses (data)schema incompatibilities. A “schema translator” is a software componentthat converts data of one specific schema to data of another specificschema. Each version of each schema component preferably has a publicidentifier. One or more schema translators can be associated with adirected pair of schema component public identifiers. A flag for eachregistered transformer indicates whether the transformation involves aloss of data. Transformer pairs that have been successfully reviewed andtested for lossless round trip are registered as such. “Registered”alludes to the registrar described above with reference to FIG. 3 andfurther described below. Each version of each application registers theschema components it depends upon.

[0318] Consistent with the present invention, client-client,client-server and server-server interactions are all mediated by XMLbased messaging. (Alternative encodings can be used when both partiescan handle them.) Standard encryption and authentication methods can andshould be used to manage these messages. The invention relies on XML andtransmission of other file types. This messaging can be accomplishedusing a wide variety of transmission techniques, including but notlimited to the following protocols, technologies and standards,individually or in combination:

[0319] TCP/IP

[0320] Hypertext Transport Protocol (http)

[0321] Secure Hypertext Transport Protocol (https)

[0322] SOAP

[0323] E-mail

[0324] Secure Socket Layer (SSL)

[0325] Short Message Service (SMS)

[0326] Cellular Digital Packet Data (CDPD)

[0327] GSM

[0328] GPRS

[0329] The server environment described above preferably also includesan incident reporting service. This is a service that trackssubscriptions to events associated with particular resources, andinforms subscribers when those events occur. Services of this type areused most commonly to track dependencies between source databases anddatabases which replicate parts of the source databases.

[0330] The incident reporting service manages relationships amongresources known to the system of the present invention. Databaserepresentations of these relationships are generally redundant, in thatthe receiving database knows about its relationship with the originatingdatabase. (The originating database may also know about the receivingdatabase.) In other words, database relationships are peer to peer, butthe incident reporting service facilitates communication between peerswhich may not be active at the same time. The purpose of the incidentreporting service is to facilitate the timely update of databases, butit has no responsibility for actually scheduling tasks. Clients of themessaging service can use the incident reporting service as a sort of“group” mechanism: messages sent to the incident reporting servicereferencing a resource are can be forwarded to each of the subscribersto that resource.

[0331] Another component of the server environment in a preferredembodiment is a task allocator (not shown). This is a service thatassigns interactive tasks to available computational resources based onsuitability to purpose (server load, access to resources, availabilityof cached database or session state). The allocator depends upon thelocation broker to identify the location of resources and theperformance monitor to determine the load on each of the relevantresources.

[0332] Another component of the server environment in a preferredembodiment is a task scheduler (not shown). This is a component thatassigns computational tasks to available computational resources basedon priority, aging, deadlines, load, etc. Typically the tasks handled inthis manner are not in response to a current user request. In order todeliver optimal performance in response to user requests, the inventionmakes provision for accomplishing preparatory tasks in the background ona time available basis. Tasks likely managed in this way by thescheduler include, but are not limited to:

[0333] synchronizing databases

[0334] creating usage reports

[0335] optimizing databases

[0336] garbage collection of unneeded synchronization packets

[0337] crawling personalized web sites

[0338] The task scheduler depends upon the task allocator to actuallyallocate tasks.

[0339] The location broker is component of the invention that can acceptan identifier for a resource and provide means to contact that resource.Resources are not necessarily local to the broker.

[0340] A directory of services is a location broker that provides anavigable index of available services. Location broker services areneeded to find database resources in the computing environment of theinvention, where resources are distributed and location is subject tochange.

[0341] Given a public identifier or system identifier the locationbroker provides access to the resource. In the simplest case, thelocation broker will satisfy a request by posting the URL given in thepublic identifier. This a degenerate case above which the locationbroker can add value. For example, the location broker can cacheresponses.

[0342] Registrar

[0343] The registrar, as mentioned above, manages metadata to enable theinvention's distributed deployment. Data associations managed by theregistrar include, but are not limited to:

[0344] schema public identifiers with schema representation

[0345] schema translators with directed pairs of schema publicidentifiers, including flag for whether translation loses information

[0346] datasource public identifier with datasource declaration

[0347] servo public identifier with servo declaration

[0348] each servo public identifier with the public identifiers of theschemas it uses

[0349] each servo public identifier with the public identifiersreferencing schema referenced in the opportunity declarations of theservo

[0350] The registrar provides mappings across these associations usestandard database techniques. In addition, the registrar calculates besttranslation path (if any) between any two schema public identifiersusing standard graph analysis algorithms.

[0351] Synchronizer

[0352] The synchronizer (310, 326 in FIG. 3) is a component that usestransaction records, synchronization point identifiers, time stamps,datasource declarations and database instance-specific parameters tomaintain correct database state across a set of related databasesmanaged by the invention. The synchronization point identifier is anidentifier uniquely representing a synchronization point for aparticular database. Recall a synchronization point is the event duringwhich a database incorporates information from another database, thusinstigating replication or updating previously replicated information.

[0353] The synchronizer is responsible for generating and processing thesynchronization packets that mediate the propagation of change amongcomponents of the invention. Data source declarations influence thetiming of synchronization by indicating when and how quickly databecomes obsolete. Time stamps are relevant when time-dependent data suchas stock quotes need to be reconciled.

[0354] Coordinating XML Stores

[0355] The invention's default approach for distributed lock managementis optimistic but centralized (on a per-resource basis). Authority toattempt change is given by the datasource declaration. Change isimplemented through one or more protocols published with the datasourcedeclaration. These protocols can be classified as either low-level “dataoriented” XML modification protocols, such as TSXUL, or higher-level“object oriented” actions which can be schema specific.

[0356] There are several levels at which a change can fail:

[0357] Data source does not accept changes: The datasource may choosenot publish a protocol for accepting changes. Such a datasource iseffectively read-only.

[0358] Individual requesting change does not have authority to makechanges (at all) to the data. This is commonly called resource-levelaccess control.

[0359] Individual requesting change does not have authority to make thespecific changes (e.g., some fields are editable, some are not). In sucha case, specification of what can be changed should be made available aspart of the change protocol so that upstream clients don't leadindividuals to attempt changes which will ultimately fail.

[0360] An individual's changes conflict with other changes made sincethe conflicting sources have a common baseline. For example, two peoplechange the same text field.

[0361] The invention attempts to detect these issues as far upstream aspossible, but the datasource itself must do it's own checking.

[0362] There are a number of ways a client can deal with “rejected”changes. The last two in the list below are used by the preferredembodiment of the invention.

[0363] Transaction managed client aborts transaction, changes nevercommitted.

[0364] Client does not apply actual change to its store beforesubmitting the request. The requested modification continues to haveunofficial status (e.g., modified data in a form).

[0365] Client has already implemented update but applies “undo” infosaved as part of synchronization point.

[0366] Client receives update synchronization packets as response,updates, shows user conflicting information, provides opportunity toretry.

[0367] Replication of data must be carefully managed as well. Inaccordance with the invention, a transient database is used, i.e., adatabase that exists only for the purpose of messaging.

[0368] Databases that are created only for the purpose of transmittingdata are transient: they need not have public IDs because it is notalways required for them to be publicly addressable. They do have systemIDs. Whenever data is replicated the root element(s) of the replicateddata carry a master” attribute which contains the local alias of themaster. Even when new elements are created in subtrees that are masteredelsewhere, they are give “ts:u” identifiers as mentioned above for thedatabase in which they are created. In situations where a client that isoriginating edits is in direct communication with the master, the “ts:u”attributes can be normalized to new identifiers scoped to the master.This is useful in situations where it is important to protect theprivacy of the originator of the data. It also reduces the number ofdatabase declarations that need to be created in context/imports.

[0369] Managing Dependencies among Applications and Schema Components

[0370] Applications and their underlying schema are expected to changeover time. New capabilities are added, ambiguities are fixed andsometimes applications are simplified. Since multiple applications maybe depending on different versions of the same schema, the inventionmust employ the schema translation infrastructure to keep everythingworking through a transition.

[0371] The invention's ability to manage schema and schema translationmeans that new schema need never be forced on users unless they wantcapability enabled by the new schema, or enabled by applications thatwork only with the new schema. Each database automatically maintainslists of imported (used) schemas. (Automatic tracking for thedependencies that instance data has on schema).

[0372] The scheduling capabilities of the server environment are used toidentify and applications requiring update and taking them through theneeded transformations in a timely manner.

[0373] Managing Schema Registered with the Invention

[0374] To fully benefit from the integration made possible by theinvention some human coordination is valuable. On their own, differentapplication developers will extend the base schema in multipleincompatible ways. To see how this works in practice, consider the hobbyof collecting. There are some shared characteristics for how collectorsoperate, but the objects collected are diverse, as are the sources ofinformation. Everyone involved in stamp collecting needs a common way todescribe the artifacts. Individuals and vendors need a way to documenttheir holdings, offer items for sale and identify items available forpurchase from others. Information about individual artifacts and issuescan come from publications, news groups, clubs, commercial websites andwebsites of issuing governments. Many of these parties have reason tohave an interest in having their information accessible in a publicdeployment of the invention, if the environment has already been wellseeded and it is reasonably easy or them to make the necessaryextensions.

[0375] All that is fine until different people begin extending thesystem in mutually incompatible ways. For example, two different partiesmight extend the schema in different ways to cover the same missingdata, say the name of the designer of a stamp. Now there are some viewsthat expect the designer of a stamp to be encoded one way, and someviews that expect it to be encoded another way. Neither set of viewswill be able to show data that is in the encoding expected by the other.Reconciling these differences requires human intervention to establish astandard schema, map the variant schemas to the standard schema, andtransform the views accordingly. The role of “schema editor” is aservice that keeps the system running smoothly by arbitrating thepreferred schema. Third party schema developers can create, using theinvention, the transformers that translate instances between schemas.Throughout this process, each variant of a schema can registered andauthenticated through the processes described above.

[0376] It will be obvious to those having skill in the art that manychanges may be made to the details of the above-described embodiments ofthis invention without departing from the underlying principles thereof.The scope of the present invention should, therefore, be determined onlyby the following claims.

1. A computer-implemented, incremental process for executing anapplication servo in a client device based on a specified set ofmatching criteria, the process comprising the steps of: selecting aservo to provide services; identifying a datasource associated with theselected servo; initializing an execution context tree structure bycreating a root node of the context tree associated with an initialinstruction of the servo; choosing a context of the context tree thatsatisfies the matching criteria; executing an instruction of the servoassociated with the chosen context; responsive to said executing step,creating zero or more new child contexts in the context tree, each newchild context including content defining a current internal evaluationstate of the process; and repeating said choosing, executing andcreating steps over subsequent instructions of the servo until nocontext satisfies the matching criteria.
 2. A process according to claim1 wherein the content of the child context includes: a pointer to anelement within the selected servo; and a pointer that identifies acurrent data context by pointing into a source tree.
 3. A processaccording to claim 1 wherein the content of the child context includes:a reference to a parent context; an ordered, potentially sparse, list ofpointers to zero or more child contexts; and definitions for any symbolsintroduced by the context.
 4. A process according to claim 1 furtherincluding, responsive to said executing step, creating zero or morechild spacers in the context tree representing unmaterialized childcontexts; and wherein said choosing a context includes choosing either acontext or a spacer.
 5. A process according to claim 4 wherein thecontext tree is implemented using a relative b-tree structure, and eachspacer is reflected in an interior node entry in the relative b-treestructure to facilitate searching unmaterialized contexts.
 6. A processaccording to claim 1 wherein the b-tree node entry includes a field totrack a linear value associated with a graphical display output object.7. A process according to claim 1 wherein the process creates andmaintains both the context tree and a geometry tree, the geometry treerepresenting the spatial structure of a predetermined graphical userinterface.
 8. A process according to claim 1 wherein the servo isdefined using a servo definition language that references XML schemadefinitions as its core vocabulary.
 9. A process according to claim 8wherein the servo definition language comprises: application dataschema; transformation rules; and opportunity rules.
 10. A servodefinition language for defining a distributed application that supportsdisconnected operation, the language comprising the following types ofrules: application data schema; transformation rules; transactionhandling rules; and interface object specifications.
 11. A servodefinition language according to claim 10 further comprising accessrules.
 12. A servo definition language according to claim 10 furthercomprising opportunity rules to realize automatic extension orintegration of servos through opportunity-based linking of an interfacecomponent representing an instance of a schema fragment to a template.13. A servo definition language according to claim 12 wherein thetemplate specifies at least one of a transformation rule, a transactionhandling rule and an interface object specification.
 14. A servodefinition language according to claim 10 and further comprising anabstract interface object definition.
 15. A servo definition languageaccording to claim 10 wherein the application data schema comprises anXML-based schema.
 16. A servo definition language according to claim 10defined using XML schema definitions XSD as the core vocabulary.
 17. Aservo definition language according to claim 10 including a view elementfor selecting a group of the said transformation rules to define atleast a part of an output interface.
 18. A servo definition languageaccording to claim 10 including a storage declaration element thatenables an author to reserve and name persistent storage for use by theservo and any other servos authorized to access the corresponding data.19. A servo definition language according to claim 18 wherein thestorage declaration element includes a locally scoped name for acorresponding storage tree and identifies a schema to which the storagetree must conform.
 20. A servo for realizing a predetermined function ona mobile client device having a user interface and utilizing at leastintermittent communication with a server environment, the servocomprising: a series of transformation elements expressed in apredetermined servo description language (SDL) consistent with apredetermined SDL schema; the servo transformation elements including adata schema declaration for defining a data type on which the servo canbe executed; and the servo transformation elements further including atleast two transformation rules, each rule for transforming selectedelements of the data type defined by the data schema from an inputdocument so as to provide output to the client device user interface;and further wherein the servo transformation elements include at leastone view declaration for selecting a group of the said transformationrules so as to define at least a part of an output interface realizableon the client device user interface.
 21. A servo according to claim 20wherein the servo is declared using a standard XSLT vocabulary extendedso as to include the view declaration element.
 22. A servo according toclaim 20 wherein the servo transformation elements include at least onestorage declaration element for declaration of a persistent storagetree.
 23. A servo according to claim 22 wherein the storage declarationelement includes a name attribute for defining a locally scoped name forthe corresponding storage tree.
 24. A servo according to claim 23wherein the storage declaration element includes identification of apredetermined storage schema to which the corresponding storage treeconforms.
 25. A servo according to claim 24 wherein the storagedeclaration element includes at least one attribute directed tospecification of a lifetime, an update policy or a destruction policyassociated with the corresponding storage tree.
 26. A servo according toclaim 24 wherein the predetermined storage schema is defined in anextensible stylesheet language.
 27. A servo according to claim 24wherein the predetermined storage schema is defined within the servo.28. A servo according to claim 24 wherein the predetermined storageschema is defined by an XML schema definition.
 29. A servo according toclaim 24 including an opportunity element to realize automatic extensionof the servo through opportunity-based linking of an interface componentrepresenting an instance of a schema fragment to a template wherein thetemplate specifies at least one of a transformation rule, a transactionhandling rule and an interface object specification.
 30. A servoaccording to claim 24 wherein the servo is declared using a standardXSLT vocabulary extended so as to include the storage declarationelement.
 31. A computing platform for distributed mobile applicationscomprising a computer-implemented server environment for interactionwith a mobile client machine over a potentially intermittentcommunication channel, the server environment including: a messagingservice for managing potentially intermittent communication between theclient machine and the server environment; a location broker componentfor locating a database associated with an identifier contained in arequest communicated from the client machine; a session manager servicefor managing an interactive session with the client machine; aninterpreter instance for processing a request assigned to it in acurrent session; storage for at least one servo, data and schema; and aregistry for managing meta data associated with servos and schemata;wherein both the servo and the data are expressed in a markup language.32. A computing platform according to claim 31 wherein the stored servois declared in a servo definition language (SDL) defined by a schemathat references the XSL vocabulary; and the SDL includes a means fordiscovering a session environment; and wherein the session environmentincludes indicia (attributes) of a physical location of the mobileclient machine, identification of the mobile client hardware, andcurrent status of the communication channel.
 33. A computing platformaccording to claim 31 wherein the SDL defines a storage declarationinstruction, and application data is available for reference in the SDLas a named input tree using a name defined in a storage declarationinstruction in the servo.
 34. A computing platform according to claim 33wherein the SDL defines the following types of rules: application dataschema; transformation rules; transaction handling rules; and interfaceobject specifications.
 35. A computing platform according to claim 34wherein the SDL further defines opportunity rules to realize automaticextension a servo through opportunity-based linking of an interfacecomponent representing an instance of a schema fragment to a template.36. A computing platform according to claim 34 wherein the SDL furtherdefines opportunity rules to realize automatic integration of multipleservos through opportunity-based linking of an interface componentrepresenting an instance of a schema fragment to a template.
 37. Acomputing platform according to claim 35 wherein the SDL specifies atleast one of a transformation rule, a transaction handling rule and aninterface object specification.
 38. A computing platform according toclaim 35 wherein the SDL further includes a view element for selecting agroup of transformation rules to define at least a part of an outputinterface.
 39. A computing platform according to claim 38 wherein theserver environment further includes a schema translator for translatingdata from one schema to another.
 40. A computing platform according toclaim 38 wherein the registry includes at least one of the followingkinds of metadata: a schema public identifier with the correspondingschema representation; a schema translator with a corresponding directedpair of schema public identifiers including flags for whether thetranslation loses information; and a datasource public identifier withcorresponding datasource declaration.